BLUEPRINT

2 핵심 능력 매트릭스

제2장: 핵심 능력 매트릭스

본 장에서는 CAP 프로토콜의 5가지 핵심 능력에 대해 전략적 수준의 기술을 수행하며, 오프라인 인가, 온라인 티켓, 세션 관리, 제어권 인계 정책 및 자원 접근 모드를 포괄한다. 각 능력은 설계 동기, 생명주기, 핵심 메커니즘 및 정책 구성 등의 차원에서 전개되어 후속 프로토콜 기술 규격 제정을 위한 상위 지침을 제공한다.

2.1 오프라인 인가(Authorization_Descriptor)

설계 동기

Authorization_Descriptor는 CAP 프로토콜의 핵심 인가 메커니즘이다. 그 설계 동기는 하나의 기본 판단에서 비롯된다: 단말이 오프라인일 때 Fay의 인수 권한을 완전히 박탈해서는 안 된다. Fay가 사전에 인간 호스트로부터 인가를 받았을 수 있기 때문이다.

현실 시나리오에서 단말 장치는 네트워크가 불가용하거나 불안정한 상태에 자주 놓인다 — 비행기 모드, 지하 공간, 원격 지역, 네트워크 장애 등. 인가 검증이 온라인 서비스에 완전히 의존한다면, 네트워크가 중단되는 순간 Fay는 단말 자원에 대한 모든 제어권을 즉시 상실하게 되며, 이는 인간 호스트(Natural_Person) 또는 공식 직위(Official_Post)가 이전에 명시적으로 인가했더라도 마찬가지이다. 예를 들어, 야외 사진작가의 iFay가 드론 조종을 도와 촬영 중, 산골짜기로 날아간 후 휴대폰 신호가 끊겼다면——오프라인 인가 메커니즘이 없으면 iFay는 즉시 드론 제어권을 잃게 되어 드론이 추락할 수 있다. 이러한 설계는 Fay의 가용성을 네트워크 상태에 심각하게 의존하게 만들어 iFay 체계가 추구하는 "지능형 에이전트의 원활한 단말 인수" 비전에 반한다.

Authorization_Descriptor는 인가 관계를 암호화 파일 형태로 단말 로컬에 영속화하여 단말이 오프라인 상태에서도 독립적으로 인가 검증을 완료할 수 있게 한다. 이 파일은 Fay가 인가받은 자원 범위, 권한 유형 및 유효 기간을 포함하며, 단말 측의 Descriptor_Validator가 네트워크 연결 없이도 합법성과 유효성을 검증할 수 있다.

생명주기 개요

Authorization_Descriptor의 생명주기는 다음 5단계를 포함한다:

발급(Issuance): Descriptor_Issuer가 인가자(Natural_Person 또는 Official_Post)의 명시적 인가를 받은 후 Authorization_Descriptor를 생성하고 발급한다. 발급 과정에는 인가 범위 결정, 유효 기간 설정, 디지털 서명 생성 등의 단계가 포함된다. 발급이 완료되면 Authorization_Descriptor는 해당 Fay 엔티티에 전달된다. 예를 들어, 사용자 장삼이 인가 관리 인터페이스를 통해 iFay에게 향후 30일간 노트북의 카메라와 마이크 사용을 인가하면, Descriptor_Issuer가 이러한 권한을 포함하는 Authorization_Descriptor를 생성하여 iFay에게 전달한다.
로컬 저장(Local Storage): Fay는 획득한 Authorization_Descriptor를 대상 단말에 제출하고, 단말은 이를 암호화 형태로 로컬 보안 저장 영역에 저장한다. 로컬 저장은 단말이 오프라인 상태에서도 인가 정보에 접근할 수 있도록 보장하며, 오프라인 인가 메커니즘의 물리적 기반이다. 예를 들어, iFay가 위 인가 파일을 장삼의 노트북에 제출하면, 컴퓨터가 이를 로컬 보안 칩에 암호화하여 저장한다.
검증(Validation): Fay가 단말 자원에 접근을 요청할 때, 단말 측의 Descriptor_Validator가 로컬에 저장된 Authorization_Descriptor를 검증한다. 검증 내용에는 디지털 서명의 합법성(Verification_Key를 사용하여 검증), 유효 기간 만료 여부, 인가 범위가 요청된 자원과 작업 유형을 포괄하는지, 폐기되었는지 여부가 포함된다. 예를 들어, iFay가 카메라 활성화를 요청하면, 단말은 인가 파일의 서명이 합법적인지, 30일 유효 기간 내인지, 카메라 사용 권한이 포함되어 있는지 확인한다.
폐기(Revocation): 인가자가 인가를 회수하기로 결정하면, 폐기 선언을 발급하여 해당 Authorization_Descriptor를 무효화한다. 폐기 선언은 다양한 채널을 통해 단말에 배포되며(아래 "폐기 선언 배포 정책" 참조), 단말은 후속 검증에서 폐기된 Authorization_Descriptor를 거부한다. 예를 들어, 장삼이 iFay의 행동이 기대에 부합하지 않음을 발견하고 카메라 사용 인가를 즉시 철회하면, 단말은 다음 검증 시 해당 iFay의 카메라 접근 요청을 거부한다.
갱신(Renewal): Authorization_Descriptor가 만료 임박하거나 인가 범위를 조정해야 할 때, Descriptor_Issuer가 새로운 Authorization_Descriptor를 발급하여 이전 버전을 대체한다. 갱신 과정은 본질적으로 새로운 발급이며, 이전 버전은 새 버전이 발효된 후 자동으로 무효화된다. 예를 들어, 30일 유효 기간이 곧 만료될 때, 장삼이 갱신을 결정하고 추가로 iFay에게 저장 장치 사용을 인가하면, Descriptor_Issuer가 새로운 인가 파일을 발급하여 이전 버전을 대체한다.

신뢰 체인 모델

오프라인 인가의 신뢰성은 완전한 신뢰 체인에 의존하며, 인가자에서 단말 측 검증기까지의 신뢰 전달 경로는 다음과 같다:

인가자(Natural_Person / Official_Post)
    │
    │ 인가 위임
    ▼
Descriptor_Issuer(인가 기술 파일 발급자)
    │
    │ Authorization_Descriptor 발급(디지털 서명 첨부)
    ▼
Fay(iFay / coFay)
    │
    │ Authorization_Descriptor 제출
    ▼
단말 측 Descriptor_Validator
    │
    │ Verification_Key를 사용하여 서명 검증
    ▼
검증 결과(통과 / 거부)

신뢰 체인의 핵심 환절:

인가자 → Descriptor_Issuer: 인가자는 안전한 인가 위임 메커니즘을 통해 발급 권한을 Descriptor_Issuer에 위임하여, 인가된 발급자만이 합법적인 Authorization_Descriptor를 생성할 수 있도록 보장한다
Descriptor_Issuer → Fay: Descriptor_Issuer는 개인 키를 사용하여 Authorization_Descriptor에 디지털 서명을 수행하고, Fay는 서명된 인가 파일을 획득한다
Fay → Descriptor_Validator: Fay는 단말에 Authorization_Descriptor를 제출하고, 단말 측의 Descriptor_Validator는 Registration_Authority가 배포한 Verification_Key를 사용하여 서명의 합법성을 검증한다
Registration_Authority → 단말: Registration_Authority는 신뢰 인프라로서 단말에 Verification_Key를 배포하여 단말이 Authorization_Descriptor의 서명 출처를 검증할 수 있도록 보장한다

폐기 선언 배포 정책

오프라인 시나리오에서 폐기 선언의 적시 배포는 핵심 과제이다. 단말은 온라인 폐기 서비스를 실시간으로 조회할 수 없는 상황에서도 가능한 한 최신 폐기 정보를 획득해야 한다. CAP 프로토콜은 다음 배포 정책을 채택한다:

로컬 폐기 목록(Local Revocation List): 단말은 로컬 폐기 목록을 유지하여 알려진 폐기된 Authorization_Descriptor 식별자를 기록한다. 단말이 네트워크에 연결될 때마다 폐기 서비스에서 최신 폐기 목록을 자동으로 동기화한다
네트워크 연결 시 능동적 동기화: 단말이 오프라인 상태에서 네트워크 연결 상태로 복구될 때, 폐기 목록을 우선적으로 동기화하여 로컬 폐기 정보가 가능한 한 최신 상태에 가깝도록 보장한다
유효 기간 안전장치: Authorization_Descriptor 자체에 유효 기간이 포함되어 있어, 폐기 선언이 적시에 전달되지 않더라도 만료된 Authorization_Descriptor는 자동으로 무효화되어 폐기 지연의 최대 영향 범위를 제한한다
다음 검증 시 적용: 단말은 Authorization_Descriptor를 검증할 때마다 로컬 폐기 목록을 확인하며, 폐기 선언이 단말에 도달하면 후속 검증 요청에서 폐기된 인가를 즉시 거부한다

2.2 온라인 티켓(Trusted_Ticket)

포지셔닝과 사용 시나리오

Trusted_Ticket은 CAP 프로토콜이 네트워크 연결 환경에서 제공하는 온라인 인가 보완 메커니즘이다. 그 핵심 포지셔닝은: 네트워크 연결 환경에서 실시간 인가 발급 및 폐기 상태 조회 기능을 제공하여 오프라인 인가의 시효성과 폐기 응답 속도 부족을 보완하는 것이다.

Trusted_Ticket의 대표적인 사용 시나리오는 다음과 같다:

임시 인가: 인간 호스트가 Fay에게 특정 자원에 대한 접근 권한을 임시로 부여해야 할 때, 완전한 Authorization_Descriptor 발급 절차를 거치지 않고 온라인 서비스를 통해 즉시 Trusted_Ticket을 발급한다. 예를 들어, 사용자가 임시로 iFay에게 문서 인쇄를 도와달라고 할 때, 휴대폰에서 원터치 인가하면 온라인 서비스가 프린터 사용만 허용하는 임시 티켓을 즉시 발급하며, 완전한 오프라인 인가 발급 절차를 거칠 필요가 없다
실시간 폐기 검증: 단말이 네트워크 연결 상태에서 Trusted_Ticket 메커니즘을 통해 인가의 폐기 상태를 실시간으로 조회하여 로컬 폐기 목록보다 더 적시적인 폐기 정보를 획득할 수 있다. 예를 들어, 회사 관리자가 방금 coFay의 회의실 장비 제어권을 철회한 경우, 네트워크에 연결된 단말은 온라인 티켓 메커니즘을 통해 즉시 이 철회를 알 수 있으며, 로컬 폐기 목록의 다음 동기화를 기다릴 필요가 없다
동적 권한 조정: 네트워크 연결 환경에서 인가 범위를 Trusted_Ticket을 통해 동적으로 조정할 수 있으며, Authorization_Descriptor를 재발급할 필요가 없다. 예를 들어, iFay가 원래 파일 읽기 권한만 가지고 있었는데, 사용자가 휴대폰에서 임시로 쓰기 권한으로 승격하면 온라인 티켓을 통해 즉시 적용된다

Authorization_Descriptor와의 관계

Trusted_Ticket과 Authorization_Descriptor 사이는 대체 관계가 아닌 보완 관계이다:

Authorization_Descriptor가 핵심: 오프라인 인가는 항상 CAP 프로토콜의 기본 메커니즘이며, Trusted_Ticket은 Authorization_Descriptor 체계와 독립적으로 존재할 수 없다
온라인 발급을 오프라인 형식으로 변환 가능: 온라인에서 발급된 Trusted_Ticket은 오프라인 사용을 위해 로컬 Authorization_Descriptor 형식으로 변환될 수 있다. 이는 Trusted_Ticket을 통해 획득한 인가가 네트워크 중단으로 인해 즉시 무효화되지 않음을 의미한다
우선순위 관계: 단말이 Trusted_Ticket과 Authorization_Descriptor를 동시에 보유할 때, 시효성이 더 강한 Trusted_Ticket이 제공하는 실시간 인가 정보를 우선 사용한다

온라인에서 오프라인으로의 저하 정책

온라인 서비스가 불가용할 때, CAP 프로토콜은 원활한 저하 정책을 실행한다:

온라인 서비스 상태 감지: 단말은 온라인 인가 서비스와의 연결 상태를 지속적으로 모니터링한다
자동 폴백: 온라인 서비스가 불가용할 때, 단말은 자동으로 로컬 Authorization_Descriptor 검증으로 폴백하여 Fay의 자원 접근을 중단하지 않는다
Trusted_Ticket 변환: 네트워크 연결 기간 동안 발급된 Trusted_Ticket은 이미 로컬 Authorization_Descriptor 형식으로 변환되어 저장되어 있어 저하 후에도 사용할 수 있다
복구 후 동기화: 온라인 서비스가 복구되면, 단말은 자동으로 Trusted_Ticket 메커니즘 사용을 재개하고 오프라인 기간 동안 누락되었을 수 있는 폐기 정보를 동기화한다

저하 과정은 Fay에게 투명하다 — Fay는 단말이 현재 온라인 티켓을 사용하는지 오프라인 인가를 사용하는지 인지할 필요가 없으며, 인가 검증 결과는 두 모드에서 일관성을 유지한다.

2.3 세션 관리(Session)

생명주기

Session(제어 세션)은 인가 검증 통과부터 접근 종료까지의 완전한 생명주기이며, 다음 3단계를 포함한다:

생성(Creation): Fay의 인가 검증이 통과되면, Protocol_Engine이 해당 Fay에 대한 Session 인스턴스를 생성한다. Session 생성 시 연관된 Fay 식별자, 대상 Terminal_Resource, 인가 권한 목록 및 생성 시간을 기록한다. 생성이 성공하면 Fay는 대상 자원에 대한 제어권을 획득한다. 예를 들어, iFay가 노트북의 브라우저 사용을 요청하고 인가 검증을 통과하면, 시스템이 브라우저에 바인딩된 제어 세션을 생성하고, iFay는 그 시점부터 브라우저를 조작할 수 있다.
활성(Active): Session 생성 후 활성 상태에 진입하며, Fay는 인가 권한 범위 내에서 바인딩된 Terminal_Resource에 대해 작업을 수행할 수 있다. 활성 기간 동안 Liveness_Detection 메커니즘이 세션의 생존 상태를 지속적으로 모니터링하여 Fay가 여전히 해당 세션을 유효하게 사용하고 있는지 확인한다. 예를 들어, iFay가 브라우저를 통해 사용자의 항공편 정보를 검색하는 동안, 지속적으로 하트비트를 전송하여 여전히 활발히 사용 중임을 나타낸다.
종료(Termination): Session은 다음 방식으로 종료될 수 있다:
- 능동적 해제: Fay가 작업을 완료한 후 능동적으로 Session을 해제하여 Terminal_Resource에 대한 제어권을 반환한다. 예를 들어, iFay가 항공편 검색을 완료한 후 능동적으로 브라우저 제어권을 해제한다
- 타임아웃 종료: Liveness_Detection이 Fay 세션이 더 이상 활성 상태가 아님을 감지하면(하트비트 타임아웃), 자동으로 Session을 종료하고 자원을 회수한다. 예를 들어, iFay가 런타임 충돌로 하트비트 전송을 중단하면, 단말이 타임아웃 후 자동으로 브라우저 제어권을 회수한다
- 폐기 종료: 인가가 폐기되면, 연관된 활성 Session이 강제 종료된다. 예를 들어, 사용자가 iFay가 부적절한 콘텐츠를 탐색하고 있음을 발견하고 즉시 인가를 철회하면, 브라우저 세션이 강제 종료된다

Session 종료 후, Fay의 해당 Terminal_Resource에 대한 제어권은 즉시 해제되며, 자원은 다른 제어자가 획득할 수 있는 상태로 복원된다.

Terminal_Resource와의 바인딩 관계

Session과 Terminal_Resource 사이에는 엄격한 바인딩 관계가 존재한다: 하나의 활성 Session은 하나의 Terminal_Resource에 대한 제어권에 대응한다.

이 바인딩 관계의 핵심 규칙:

일대일 바인딩: 각 활성 Session은 하나의 구체적인 Terminal_Resource에 바인딩되며, Fay는 Session을 통해 해당 자원에 대해 작업을 수행한다. 예를 들어, iFay가 '전면 카메라'에 바인딩된 Session을 얻으면, 이 Session을 통해 전면 카메라만 조작할 수 있고 마이크 조작에는 사용할 수 없다
배타적 제어: 배타적 접근이 필요한 작업 모드(write, execute, configure)의 경우, 동일한 Terminal_Resource에 동일 시점에 최대 하나의 활성 배타적 Session만 존재할 수 있다. 예를 들어, iFay-A가 write 모드로 SD 카드에 데이터를 쓰고 있을 때, iFay-B는 동시에 SD 카드의 write Session을 얻을 수 없다
다중 읽기 동시성: read 모드의 경우, 동일한 Terminal_Resource에 여러 활성 읽기 전용 Session이 동시에 존재할 수 있다. 예를 들어, iFay-A와 iFay-B는 동시에 read 모드로 GPS 모듈의 위치 데이터를 읽을 수 있다
생명주기 연동: Terminal_Resource가 불가용할 때(예: 하드웨어 분리), 해당 자원에 바인딩된 모든 활성 Session이 종료된다. 예를 들어, 사용자가 USB 카메라를 분리하면, 해당 카메라에 바인딩된 모든 Session이 자동으로 종료된다

생존 감지 메커니즘

Liveness_Detection(생존 감지)은 장기 연결과 애플리케이션 계층 하트비트를 결합하여 Fay 세션이 여전히 활성 상태인지 감지하며, 그 설계 의도는 실효된 세션이 점유한 자원을 적시에 회수하는 것이다.

생존 감지의 작동 메커니즘:

장기 연결 유지: Fay와 단말 사이에 장기 연결을 통해 통신 채널을 유지하며, 연결 상태가 생존 감지의 기본 신호로 사용된다
애플리케이션 계층 하트비트: 장기 연결 위에서 Fay가 주기적으로 애플리케이션 계층 하트비트 메시지를 전송하여 현재 Session을 여전히 유효하게 사용하고 있음을 표명한다. 하트비트 간격과 타임아웃 임계값은 구성 가능하다
이중 판정: 장기 연결 단절과 애플리케이션 계층 하트비트 타임아웃이 동시에 충족될 때만 Session 실효로 판정한다. 이러한 이중 판정 메커니즘은 일시적인 네트워크 변동으로 인한 오판을 방지한다
자원 회수: Session이 실효로 판정된 후, Protocol_Engine이 자동으로 해당 Session을 종료하고 점유하고 있던 Terminal_Resource를 해제하여 다른 제어자가 자원을 획득할 수 있게 한다

2.4 제어권 인계 정책(Handover_Policy)

핵심 시나리오

제어권 인계는 여러 제어자가 동일한 Terminal_Resource를 순차적으로 사용해야 하는 시나리오에서 발생한다. CAP 프로토콜은 두 가지 핵심 인계 시나리오를 정의한다:

Fay 간의 제어권 이전: 한 Fay가 보유한 Terminal_Resource 제어권을 다른 Fay에게 이전한다. 예를 들어, 데이터 수집을 담당하는 iFay가 작업을 완료한 후 카메라 제어권을 영상 통화를 담당하는 iFay에게 인계한다. 또한, 스마트 공장에서 품질 검사를 담당하는 coFay가 제품 촬영을 완료한 후 산업용 카메라 제어권을 포장을 담당하는 coFay에게 넘긴다
Fay와 인간 사용자 간의 제어권 이전: Fay가 제어권을 인간 사용자에게 반환하거나, 인간 사용자가 제어권을 Fay에게 위임한다. 예를 들어, 드론이 iFay에 의해 자율 순항 중 조종사가 이상 기상을 발견하여 수동 조종이 필요한 경우, iFay가 즉시 비행 제어권을 양도한다. 날씨가 호전되면 조종사가 제어권을 iFay에게 다시 넘겨 자율 비행을 계속한다. 또한, 사용자가 수동으로 문서를 편집하다가 iFay에게 레이아웃을 도와달라고 할 때, 문서 편집기의 제어권을 임시로 iFay에게 넘기고, 레이아웃 완료 후 iFay가 제어권을 반환한다

정책화 구성 기능

Handover_Policy는 정책화된 구성 기능을 제공하며, 다음 3가지 정책 유형을 지원한다:

우선순위 규칙 스크립트(Priority Rule Script): 사전 정의된 규칙 스크립트를 통해 제어권 인계의 우선순위를 결정한다. 규칙 스크립트는 Fay의 역할, 작업 긴급도, 자원 유형 등의 요소를 기반으로 우선순위 점수를 계산하며, 우선순위가 높은 제어자가 자원 제어권을 획득한다. 이 정책은 인계 규칙이 명확하고 사전에 정의할 수 있는 시나리오에 적합하다. 예를 들어, 의료 시나리오에서 긴급 경보를 담당하는 iFay의 우선순위는 일상 데이터 수집을 담당하는 iFay보다 항상 높으며, 양자가 동시에 통신 모듈 사용을 요청하면 긴급 경보 iFay가 자동으로 제어권을 획득한다.
AI 모델 실시간 판정(AI Model Real-time Decision): AI 모델이 현재 컨텍스트를 기반으로 제어권 배분을 실시간으로 판정한다. AI 모델은 여러 제어자의 작업 상태, 자원 사용 긴급성, 과거 인계 패턴 등의 요소를 종합적으로 고려하여 결정을 내린다. 이 정책은 인계 규칙이 복잡하고 정적 규칙으로 포괄하기 어려운 동적 시나리오에 적합하다. 예를 들어, 스마트 홈에서 보안 감시를 담당하는 iFay와 영상 통화를 담당하는 iFay가 동시에 카메라를 요청하면, AI 모델이 현재 보안 위협이 있는지, 통화가 긴급한지 등의 컨텍스트 정보를 기반으로 실시간으로 우선순위를 판정한다.
인간 사용자 결정(Human User Decision): 제어권 인계의 결정권을 인간 사용자에게 부여한다. 여러 제어자가 동일한 자원을 경쟁할 때, 단말이 인간 사용자에게 선택 인터페이스를 제시하고 인간 사용자가 어느 쪽에 제어권을 부여할지 결정한다. 이 정책은 고민감 자원이나 인간의 판단이 필요한 시나리오에 적합하다. 예를 들어, 두 iFay가 동시에 사용자의 뱅킹 앱 사용을 요청하면, 단말이 프롬프트를 표시하여 사용자가 어느 쪽에 인가할지 결정하게 한다. 금융 거래에는 인간의 최종 확인이 필요하기 때문이다.

세 가지 정책 유형은 Terminal_Resource 단위로 독립적으로 구성할 수 있으며, 동일한 단말의 서로 다른 자원에 서로 다른 인계 정책을 적용할 수 있다.

원자성 보장

제어권 인계 과정은 원자성 요구사항을 충족해야 한다: 임의의 시점에서 하나의 Terminal_Resource에는 최대 하나의 활성 제어자만 존재한다.

원자성 보장의 구현 원칙:

해제 후 획득: 인계 과정에서 원래 제어자의 Session이 먼저 종료되고, 새로운 제어자의 Session이 그 후에 생성되어 두 제어자가 동시에 동일한 자원의 제어권을 보유하는 상태가 발생하지 않도록 보장한다. 예를 들어, 드론의 비행 제어권을 iFay-A에서 iFay-B로 넘길 때, iFay-A의 제어 세션이 먼저 종료되고 iFay-B의 제어 세션이 생성된다——두 iFay가 동시에 드론 비행을 제어하는 상황은 절대 발생하지 않는다
분할 불가: 인계 작업은 하나의 전체로서 실행되며, 완전히 성공(원래 제어자 해제 + 새로운 제어자 획득)하거나 완전히 실패(인계 전 상태로 롤백)한다
중간 상태 비노출: 외부 관찰자가 임의의 시점에서 보는 자원 제어 상태는 항상 일관적이며, 인계 과정 중의 중간 상태를 관찰할 수 없다

타임아웃 처리 원칙

제어권 인계 과정은 다양한 원인(네트워크 지연, 제어자 무응답 등)으로 인해 예상 시간 내에 완료되지 않을 수 있다. CAP 프로토콜의 인계 타임아웃 처리 원칙은: 타임아웃으로 완료되지 않은 인계는 인계 전 상태로 롤백하여 원래 제어자의 세션을 변경 없이 유지해야 한다.

구체적 처리 규칙:

타임아웃 임계값 구성 가능: 각 인계 정책에 독립적인 타임아웃 임계값을 구성하여 서로 다른 시나리오의 시효 요구사항에 적응할 수 있다
롤백 보호: 타임아웃이 트리거되면 인계 작업이 자동으로 롤백되며, 원래 제어자의 Session은 활성 상태를 유지하고 영향을 받지 않는다. 예를 들어, iFay-A가 카메라를 제어하면서 iFay-B에게 제어권을 넘기려 했으나, iFay-B가 네트워크 지연으로 규정 시간 내에 응답하지 못하면, 핸드오버가 자동으로 롤백되어 iFay-A가 카메라 제어를 계속한다
알림 메커니즘: 타임아웃 롤백 후, Protocol_Engine이 관련 제어자에게 인계 실패 알림을 전송하여 타임아웃 원인을 설명한다
재시도 정책: 인계 실패 후, 정책 구성에 따라 자동 재시도 여부 또는 수동 개입 대기 여부를 결정할 수 있다

2.5 자원 접근 모드(Resource_Access_Mode)

등급 모델

Resource_Access_Mode는 작업 유형에 따라 자원 접근을 4가지 모드로 분류하며, 낮은 것에서 높은 것으로의 권한 등급을 형성한다:

read(읽기): Terminal_Resource에 대한 읽기 전용 접근으로, 자원 상태를 수정하지 않는다. 예를 들어 온도 센서의 실시간 데이터 읽기, 사용자 앨범의 사진 보기, GPS 모듈의 현재 위치 정보 획득 등이다. read 모드는 공유 가능하며, 여러 Fay가 동시에 read 모드로 동일한 자원에 접근할 수 있다——예를 들어, 여러 iFay가 동일한 온도 센서의 데이터를 동시에 읽어도 서로 간섭하지 않는다.
write(쓰기): Terminal_Resource에 대한 데이터 쓰기 또는 상태 수정이다. 예를 들어 촬영한 사진을 저장 장치에 저장, 스마트 홈 기기의 온도 설정값 변경, 문서에 내용 쓰기 등이다. write 모드는 배타적이며, 동일 시점에 하나의 제어자만 write 모드로 자원에 접근할 수 있다——예를 들어, 두 iFay가 동일한 파일에 동시에 데이터를 쓸 수 없다. 데이터 손상을 초래하기 때문이다.
execute(실행): Terminal_Resource에 대한 작업 명령 실행이다. 예를 들어 휴대폰의 내비게이션 앱 실행, 드론의 이륙 명령 트리거, 프린터의 인쇄 작업 실행 등이다. execute 모드는 배타적이며, 작업 명령의 실행이 다른 제어자에 의해 방해받지 않도록 보장한다——예를 들어, iFay가 드론의 착륙 절차를 제어하는 동안 다른 iFay가 동시에 이륙 명령을 보낼 수 없다.
configure(구성): Terminal_Resource에 대한 시스템 수준 구성 변경이다. 예를 들어 카메라의 해상도와 프레임 레이트 파라미터 변경, 네트워크 방화벽 규칙 조정, 블루투스 모듈의 페어링 설정 변경 등이다. configure 모드는 배타적이며 고권한으로, 일반적으로 더 높은 수준의 인가가 필요하다——예를 들어, 라우터의 보안 정책을 변경하는 것은 단순히 네트워크 상태를 읽는 것보다 더 높은 인가 수준이 필요하다.

읽기-쓰기 잠금 본질

Resource_Access_Mode의 동시성 제어는 본질적으로 읽기-쓰기 잠금(Read-Write Lock) 모델이다:

read 작업은 여러 Fay의 동시 접근을 허용한다: 여러 Fay가 동시에 동일한 Terminal_Resource의 read 모드 Session을 보유할 수 있으며, 서로 간섭하지 않는다. 이는 읽기-쓰기 잠금의 공유 잠금(Shared Lock)과 유사하다. 예를 들어, 세 iFay가 동일한 기상 센서의 온습도 데이터를 동시에 읽어도 서로 차단하지 않는다
write, execute 및 configure 작업은 배타적 제어를 요구한다: 어떤 Fay가 write, execute 또는 configure 모드로 자원에 접근할 때, 다른 Fay는 동시에 어떤 쓰기 유형 모드로도 해당 자원에 접근할 수 없다. 이는 읽기-쓰기 잠금의 배타적 잠금(Exclusive Lock)과 유사하다. 예를 들어, 한 iFay가 SD 카드에 비디오 파일을 쓰고 있을 때, 다른 iFay가 동시에 같은 SD 카드에 사진을 쓸 수 없다
읽기-쓰기 상호 배제: 자원에 활성 write, execute 또는 configure Session이 존재할 때, 새로운 read 요청도 배타적 Session이 해제될 때까지 차단된다. 반대로, 자원에 활성 read Session이 존재할 때, write, execute 및 configure 요청은 모든 read Session이 종료될 때까지 대기한다. 예를 들어, iFay가 설정 파일을 수정 중(write 모드)일 때, 다른 iFay가 해당 파일을 읽으려 해도 쓰기가 완료될 때까지 기다려야 한다. 불일치한 중간 상태를 읽는 것을 방지하기 위해서이다

이러한 읽기-쓰기 잠금 모델은 데이터 일관성과 작업 안전성을 보장하면서 read 작업의 동시성 성능을 최대화한다.

Session 권한과의 관계

Resource_Access_Mode는 Session의 인가 권한과 밀접하게 연관된다: Session의 인가 권한 목록이 Fay가 수행할 수 있는 작업 유형을 결정한다.

구체적 관계는 다음과 같다:

권한 목록 제약: 각 Session은 생성 시 인가 권한 목록을 수반하며, 이 목록은 Authorization_Descriptor 또는 Trusted_Ticket에 정의된 권한 범위에서 비롯된다. Fay는 권한 목록에 포함된 모드로만 자원에 접근할 수 있다
최소 권한 원칙: Session의 권한 목록은 최소 권한 원칙을 준수해야 하며, Fay가 현재 작업을 완료하는 데 필요한 최소한의 권한 모드만 포함해야 한다
권한 상승 불가: Session 생성 후, 세션 생명주기 내에서 권한 목록을 상승시킬 수 없다. Fay가 더 높은 권한의 접근 모드가 필요한 경우, 새로운 인가 검증을 통해 새로운 Session을 생성해야 한다
권한 계층 비포함: 높은 권한 모드가 낮은 권한 모드의 기능을 자동으로 포함하지 않는다. 예를 들어, configure 권한을 보유한다고 해서 자동으로 read 권한을 갖는 것은 아니며, 각 접근 모드는 독립적인 인가가 필요하다